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ABSTRACT 


Today mobile devices have become powerful and ubiquitous. The conveniences 
afforded by these devices do not come without a cost, however. The use of mobile 
devices and mobile networks poses a significant risk to privacy. Four privacy 
requirements for mobile networks are identified: content privacy, identity privacy, 
location privacy, and authentication. This work focuses on content privacy. Two threats 
to content privacy are identified: the casual observer and the attacker. This work seeks to 
provide content privacy protection against the identified threats in mobile networks used 
by first responders. TwiddleNet, a mobile network designed for the data dissemination 
requirements of first responders, was used as a platform for implementation. 

A network virtualization technique was used in order to provide content privacy 
protection. This allows TwiddleNet users to share content on a per-group basis among 
virtual networks of user groups. It was found that this virtualization technique 
successfully provided content privacy protection from the threat of a casual observer, but 
not from an attacker. Providing adequate protections from the attacker threat requires 


more sophisticated measures and is left to future work. 
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I. INTRODUCTION 


Over the last several years, mobile devices have become increasingly capable and 
ubiquitous. The term mobile device in the context of this work includes cell phones, 
smart phones, and network-enabled Personal Digital Assistants (PDAs). The popularity 
of these devices has led to some striking numbers in terms of market penetration. 
According to research firm Informa [1], in November 2007, worldwide mobile phone 
subscriptions reached 3.3 billion — equivalent to half the global population. Of course 
this number is an aggregate value for all the world’s nations. Some countries have higher 
penetration rates than others. Eurostat, an organization that tracks statistics for European 
Commission nations, reported that there are nearly 95 mobile phones for every 100 
Europeans [2]. Penetration is as high as 158% in Lithuania [2] meaning some people 


own multiple devices. 


In addition to being extremely popular, mobile devices are more powerful than 
ever. The processing power of today’s mobile devices is greater than that of the desktop 
PCs used in the 1990s [3]. The content capture and communication capabilities of 
modern mobile devices have opened the door for a wide variety of new services. In 
addition to voice, text, and e-mail services that have always been popular, it is now 
possible for mobile devices to support streaming multimedia and video conferencing. 
Large companies, like Microsoft and Intel, have recognized the value of the growing 
mobile technology market and are working vigorously to capitalize upon the demand. 
The importance of mobile technology to such companies was seen at the January 2008 
Consumer Electronics Show where Microsoft chairman Bill Gates remarked, ““The trend 
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now is to have information wherever you want [4].” This trend echoes the needs of the 
military as well as first responders for “the right information, at the right place, at the 


right time [5].” 


The power and ubiquity of mobile devices does not come without a cost, 
however. The use of mobile devices and networks comes with significant privacy 


challenges. This thesis explores an implementation of privacy protection for mobile 


networks used by first responders via network virtualization. Herein network 
virtualization is defined as methods used to create a logically and/or physically separated 
set of resources running on top of a single physical network. TwiddleNet, a wireless 
system comprised of mobile devices, will be used as a platform for proof-of-concept and 


implementation. 
A. DEFINITION OF PRIVACY 


Privacy can mean many things depending on the context of the situation. Calcutt 
broadly defines privacy as “the right of the individual to be protected against intrusion 
into his personal life or affairs ... by direct physical means or by publication of 
information [6].” As noted in [7], privacy can be broken down into four separate 
concepts: information privacy, bodily privacy, privacy of communications, and territorial 
privacy. Information privacy refers to controls placed on the collection and handling of 
personal data, such as credit information, and medical and government records. Bodily 
privacy deals with the protection of people’s physical selves against invasive procedures, 
such as genetic tests, undue drug testing, and cavity searches. The security and privacy 
of mail, telephones, e-mail and other forms of communication is covered by privacy of 
communications. Territorial privacy involves the setting of limits on intrusion into the 


domestic and other environments such as the workplace or public space. 


This thesis will concentrate on information privacy and privacy of 
communications, as the other concepts are not related to the context of this work. From 


here on these concepts will more generally be referred to as “content privacy.” 
B. PRIVACY REQUIREMENTS FOR MOBILE NETWORKS 


Users of mobile networks may require privacy so as to prevent an attacker from 
learning information, such as where they live, where they work, whom they communicate 
with, and what they say. These privacy issues have been a topic of a great deal of study. 
Privacy requirements most often identified in literature include content privacy, identity 


privacy, location privacy, and authentication. 


Content privacy was previously defined in the discussion of information privacy 
and privacy of communications. At the most basic level, content privacy can be thought 
of as confidentiality. Users require that their information is not accessible to 
unauthorized parties either during transmission across the network or when stored in a 


record system. 


Identity privacy deals with protecting a user’s name or other identifiers that could 
be used to uniquely identify him [8]. Users may want to communicate anonymously or 
pseudonymously without revealing their actual identity. They may want to reveal their 
identity only to the other communicating party while remaining anonymous to any 
intermediaries or eavesdroppers, or they may want to remain anonymous with respect to 


the communication network itself [8], [9]. 


Location privacy typically refers to privacy of the user’s point of attachment to 
the network, 1.e., their network location or address. The aim of location privacy is to 
prevent an attacker or observer from linking the two locations to the same user when that 
user changes points of attachment to the network [10]. Privacy of geographic location 
can be a concern, too, as it is possible to ascertain the rough location of a transmitter by 
triangulation or signal analysis; however protection against these methods is beyond the 


scope of this work. 


Authentication refers to a process by which a user verifies that a communicating 
party is in fact who they claim to be. This is required to prevent an adversary from 
impersonating a legitimate user and thereby gaining access to privileged information. 
Ideally, mutual authentication is in place, where a user authenticates himself to the 


network and the network authenticates itself to the user. 


C; PRIVACY REQUIREMENTS FOR FIRST RESPONDERS 


1. General Requirements 


First responders may come from many disparate organizations and agencies. It is 
not uncommon to have individuals from fire, police or other law enforcement, medical, 


military, federal, state, and local government agencies, as well as non-government 
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agencies, responding to an event. Members from all these groups may require access to 
the mobile network in order to do their jobs. Each group may have different 
requirements in terms of the level of privacy needed. Therefore, as a general 
requirement, each group of first responders needs to be able to keep their information 
separate from other groups as the situation dictates. A group also should be able to share 


information with all other groups if desired. 


2. Specific Requirements 


a. Medical Information 


As previously mentioned, TwiddleNet will be the platform used for 
implementation of this thesis work. A typical use case scenario for TwiddleNet involves 
emergency medical personnel using the system to gather triage information about victims 
of a natural disaster or other mass casualty incident. Medical information of this type is 
subject to requirements delineated in the Health Insurance Portability and Accountability 
Act (HIPAA) [11], which establishes standards for the security and privacy of patient 
health information. HIPAA restricts the use and disclosure of patient health information. 
Therefore, it is desirable to restrict the access to this information to medical personnel 


only. 


b. Privacy Act Information 


Information about U.S. citizens or permanent residents collected by first 
responders working for the Department of Defense (DoD) or other federal government 
agencies is subject to the provisions of the Privacy Act of 1974 [12]. Such information 
includes education and medical information, financial transactions, criminal or 
employment history, and any identifiers assigned to an individual such as a Social 
Security Number [13]. The purpose of the Privacy Act is to regulate the collection, 


maintenance, use, and dissemination of personal information by federal agencies. In 


keeping with this purpose, any personal information collected by first responders covered 
by the act should be handled in such a way as to prevent inadvertent disclosure to persons 


without a need to know. 


c. Military Information 


First responder teams often include military personnel. Military members 
typically will have requirements for private communication of sensitive information, such 
as that pertaining to force protection. In this case, it is desirable to restrict the access of 


this information to military and perhaps law enforcement personnel. 


D. THREAT TO PRIVACY IN MOBILE NETWORKS 


This work will consider two general categories of threats to privacy in mobile 
networks: eavesdropping and surveillance, and the threat posed by the use of unique 


identifiers. 


iF Eavesdropping and Surveillance 


Wireless networks are inherently insecure due to the nature of the medium. Ina 
wireless shared medium, assuming all stations are using the same protocols, any station 
can receive all traffic from other stations that are within range and can transmit to any 
station within range. Thus, any traffic that is sent unencrypted can be easily intercepted. 
This represents a threat not only to the content privacy of a user’s communications, but 
also to identity and location privacy, as intercepted traffic may be analyzed to ascertain 
certain unique identifiers (discussed in the next section) that can lead to a compromise in 


privacy. 


Two types of parties may be seen as posing a threat by eavesdropping or 
observation: casual observers and attackers. A casual observer herein is defined as 
another user of the mobile network who may have access to, or receive information sent 
by a user, but did not actively seek out that information. For example, in the current 
TwiddleNet implementation all active users of the system receive notification of new 
content that a user has made available regardless of the user’s desire for privacy control. 
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Addressing this threat is the primary focus of this work. The implementation work done 
for this thesis allows TwiddleNet users to have more control over the recipients of their 
notifications. For instance, if a medical responder wishes only to alert other medical 
users, due to concerns over patient privacy, he can do so, preventing other users, such as 


fire or police responders, from having access to the information. 


The second party seen as posing a threat via eavesdropping is an attacker. An 
attacker is considered to be an individual who actively seeks out information that he 
would not otherwise have access to. For instance an attacker may use a “packet sniffer” 
or protocol analyzer to glean information from the wireless medium. This threat is 
normally addressed through the use of encryption and authentication. In Wireless Local 
Area Networks (WLANs) based on the IEEE 802.11 standard, three cryptographic 
protocols are commonly used: Wired Equivalent Privacy (WEP), the Temporal Key 
Integrity Protocol (TKIP), and the Counter Mode with Cipher Block Chaining Message 
Authentication Code Protocol (CCMP) [14]. WEP and TKIP are based on the Rivest 
Cipher 4 (RC4) algorithm, and CCMP is based on the Advanced Encryption Standard 
(AES). In Wireless Wide Area Networks (WWANSs), like the Global System for Mobile 
Communications (GSM) cellular networks, the encryption algorithms used are dependent 


on the particular service provider [15]. 


It should be noted that there is a great deal of concern among privacy groups 
surrounding the threat posed by surveillance of mobile networks (indeed any electronic 
communications) on the part of law enforcement and intelligence agencies [16], [17]. 
This is not considered as a threat in this work, as law enforcement agencies, after 
obtaining a warrant, are authorized to conduct such surveillance and compliance by 


network operators with this type of surveillance is required by law [18], [19], [20], [21]. 


2 Unique Identifiers 


As mentioned above, encryption is commonly employed to ensure content privacy 
in mobile networks. A user’s privacy may still be at risk however, due to unique 


identifiers used in network protocols that may lead to a compromise in identity or 


location privacy. Even with encryption in place such identifiers may reveal the user’s 


identity and activities to anyone within transmission range. 


An overview of some protection mechanisms aimed at addressing this threat is 
presented in Chapter II. Implementation of protection measures for unique identifiers is 


beyond the scope of this work however. 


E. OBJECTIVE 


The objective of this thesis is to implement privacy measures in mobile networks 
for first responders using network virtualization. The following research questions will 
be addressed: 1) Is network virtualization an appropriate choice for implementing 
privacy protections? 2) How well does the implementation address the stated privacy 


requirements? 


F. SCOPE 


The scope of this thesis is limited to providing content privacy protection for 
mobile networks. TwiddleNet will be used as the platform for implementation. The 
scope of work is limited to those changes to the code and architecture of the existing 
TwiddleNet system necessary to accomplish the stated objective. Work will be limited to 
the applications layer as the use of techniques that require modified kernel modules and 


network card drivers are not possible on the devices available to the student. 


G. ORGANIZATION 


The rest of this document is organized as follows. Chapter II covers background 
information on the TwiddleNet system and related work in the area of privacy protections 
for mobile networks. Chapter III outlines the design of the new version of TwiddleNet 
while Chapter IV details implementation aspects of the privacy protection measures. 


Chapter V concludes and discusses future work. 
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I. BACKGROUND 


A. TWIDDLENET OVERVIEW 


TwiddleNet is a distributed system of mobile devices. The system harnesses the 
power of today’s mobile devices to create a network of mobile personal servers. The 
content capture and networking capabilities of the devices allow TwiddleNet users to 
capture and publish information in real time, while at the same time retaining ownership 
control of published content. In this way, content is made available that is otherwise not 


readily accessible to anyone but the device owner. 


Designed to be run on handheld devices, TwiddleNet is most useful for first- 
responder networking and information-sharing tasks that require immediate content 
capture and dissemination [22]. The system is well suited to first responder applications 
due to the fact that it runs on lightweight devices, can be set up quickly, and supports 


real-time information exchange. 


The following is a brief overview of the major components that make up 


TwiddleNet and how they work together in a typical information-sharing scenario. 
1. Client 


A TwiddleNet Client consists of the Client software running on a mobile device. 
The current implementation runs on HP iPAQ hw6945 smartphones with the Windows 
Mobile 5 operating system, utilizing the .NET 2.0 Compact Framework. The Client has 
three primary functions: 1) to create metadata for new content and notify the Portal of its 
availability, 2) to provide an interface for a user to discover and download new content, 


and 3) to serve content to other Clients. 
Ze Portal 


The TwiddleNet Portal consists of the Portal software running on a standard PC 


running any Windows operating system capable of supporting the .NET 2.0 Framework. 
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In the current implementation, the Portal is typically run on an OQO ultra mobile PC, 


which is more portable than a laptop or desktop computer [23]. 


The Portal’s primary function is to act as a gateway to the network of mobile 
devices. It acts as a central repository for metadata describing shared content. Using the 
Client software, a user can search for specific content among the metadata residing on the 
Portal. The Portal also houses information on all TwiddleNet users and keeps track of the 
IP address currently assigned to each user’s device. Additionally, the Portal can cache 
content, temporarily taking on content serving duties, thus easing the burden on resource- 


strapped clients. 


3. Command Post 


The Command Post is a program that performs some of the functions of a 
TwiddleNet Client. It is meant to run on a Windows laptop or desktop PC. The 
Command Post is capable of receiving TwiddleNet alerts and automatically retrieves the 
content associated with each alert it receives. It then builds web pages displaying that 
content. The web server software that hosts the content is collocated on the machine 


running the Command Post software. 


The Command Post is envisioned to be used at a command center or headquarters. 
It is intended to serve as a situational awareness tool providing real-time information to 


the commander of an operation in order to facilitate timely decision making. 


4. TwiddleNet Operation 


When a user has content to share, he places the content in a designated directory 
in the device’s file system. This may be done manually by the user or automatically by 
the camera software on the user’s device, for example. The TwiddleNet Client software 
monitors this directory and automatically generates metadata for the content according to 
the user’s preferences. This metadata is then sent to the Portal, serving as a notification 
that new content is available (Figure 1, Step 1). The metadata is in XML format and 
includes descriptive items (or “tags’’), such as the username of the creator/publisher, file 


name, file size, etc., as well as user defined tags. A full description of the metadata 
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generation process is given in [24]. See also [25] for details on a specialized user-defined 


tagging scheme for medical personnel engaged in triage work. 


Once the Portal receives metadata for new content, it alerts other Clients via 
another XML-based message containing the metadata, notifying them that new content is 
available (Figure 1, Step 2). The Client software displays a notification to the user upon 
receipt of such an alert. The user can then choose to download the content (Figure 1, 
Step 3). The download will be via an HTTP GET method, normally directly from the 
publisher of the content, unless the content is cached on the Portal. As previously 
mentioned, content may be temporarily cached on the Portal due to power or bandwidth 
limitations on the part of the publisher’s device. In the case that content is cached, the 
Portal will retrieve the content from the publishing device using the same mechanism. 
See [25] for a detailed description of the caching process. 
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Figure 1. TwiddleNet System Operation 
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B. RELATED WORK IN PRIVACY PROTECTION FOR MOBILE 
NETWORKS 


This section outlines some common techniques found in the literature for 


providing privacy protection in mobile networks. 
1. Anonymity 


Anonymity can be used to provide identity protection for users. It should be 
noted that identity privacy is closely linked with location privacy: If an attacker cannot 
correlate an identifier with a particular user as that user moves around in the network, 


then the attacker cannot track that user’s location. 


Numerous examples of anonymity being employed in mobile networks can be 
found in the literature. Aura and Zugenmaier mention the use of proxies to provide 
anonymity [8]. When a proxy (or any network address translation device) is used, traffic 
from multiple users behind the device appears to be originated at one address. In this 
way, a user can “hide in the crowd” among the group of users behind the proxy. An 
attacker cannot discern one user’s traffic from another’s based solely on identifiers such 
as IP or MAC address since all traffic is coming from the address of the proxy. It should 
be noted that this technique alone cannot prevent an attacker from identifying a user 
through traffic analysis or indirectly through the context of the communication if the 


actual content of the communication is accessible. 


Digital mixes can also provide anonymity. Askwith, Merabti, Shi, and Whiteley 
propose the use of a digital mix network in the Global System for Mobile 
Communications (GSM) [9]. A digital mix enables two parties to communicate without 
unauthorized parties being able to determine either the message content or the source and 
destinations of the messages. Thus, a user can communicate anonymously through a 


digital mix network. 


The solution presented in [10] makes use of the Host Identity Protocol (HIP) [26]. 
HIP allows anonymous identifiers to be created by end users. Users can communicate 


anonymously to other HIP enabled nodes using these identifiers. 
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2. Pseudonyms 


Pseudonyms are often used to protect identity privacy, and thereby, location 
privacy, in mobile networks. In Wireless Local Area Networks (WLANs), the 
pseudonym is normally in the form of a temporary identifier, such as an IP or MAC 
address. In the implementation discussed in [27], temporary disposable MAC addresses 
are used. Each time a client creates a new association with an access point it randomly 
generates a new valid MAC address to use during that session. A similar idea is 
presented in [28] where a client is given IP and MAC addresses by the access point from 
a pool of valid addresses each time a new association is created. The idea here is that by 
frequently changing these unique identifiers, an attacker would not be able to link 
different communications to a specific user or track that user as he changes locations 


within the network. 


Pseudonyms are also used in Wireless WWANSs. In GSM a pseudonym called the 
Temporary Mobile Subscriber Identity (TMSI) is used to protect the International Mobile 
Subscriber Identity (MSI) on the radio path [15]. In a similar manner to that described 


above, the TMSI can be changed for every call setup. 
3. Encryption 


Encryption is commonly used to provide content privacy in wireless networks. 
For instance, the Wired Equivalent Privacy (WEP) and WiFi Protected Access (WPA) 
encryption protocols are heavily used in 802.11 based WLANs. The keys used by 


encryption protocols can also be used in support of authentication. 


Encryption can also provide identity privacy by hiding identifiers in the 
application layer. Identifiers like e-mail user names would be hidden in encrypted traffic 


preventing an attacker from associating the traffic with a particular user [28]. 


Furthermore, if transport layer identifiers, like port numbers, are hidden, 
encryption can mask the type of communication (e-mail, web browsing, etc.) being 
conducted. This can make it more difficult for an attacker to identify a particular user 


based on knowledge of past activity. 
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4. Virtualization 


Virtualization has been used as a technique to protect user privacy in IP based 
networks. While most work in this area does not address mobile networks specifically, 
some could be applied to WLANs at least, if not WWANs as well, provided the mobile 
devices involved are capable of running the software required. These software 
requirements typically include running modified kernel modules and/or modified network 
drivers or virtual machine monitors (VMMs), virtual network interfaces, and virtual 


switching or routing software. 


The approach used in [29] involves protocol stack virtualization where each 
application being run by a user will have its own virtual network stack. This partitioning 
scheme addresses linkability, preventing a privacy violation in one application from 
affecting others. Previously mentioned techniques for protecting identity and location 
privacy such as the use of temporary addresses can be implemented in each virtual stack 
on a per-application basis rather than forcing one protocol stack to meet the needs of 


various different applications. 


Cabuk, Dalton, Ramasamy, and Schunter use existing technologies such as 
Ethernet encapsulation, virtual LAN tagging, and virtual private networks to implement 
virtual network enclaves [30]. The framework developed by the authors allows for 
communication between enclaves to be governed by an input security model. While this 
work doesn’t specifically address privacy issues, in theory a system such as this could be 
used to provide separation between groups of users in a mobile network in order to 


provide privacy protection. 
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lil. DESIGN 


A. OVERVIEW 


Since the TwiddleNet system operates at the application layer, the strategy for this 
implementation focuses on the application layer. The design for this work is such that 
privacy protection can be achieved by modifying the TwiddleNet software in order to 
change the system’s behavior. The system was modified so that users can be partitioned 
into groups and information can be shared with only the groups desired by the sharing 
user, thus providing privacy protection. An application layer implementation is 
preferable to other strategies mentioned in Chapter II, which require changes at lower 
levels, because all the application program code is available for inspection and 
modification. Furthermore, programming at the application layer in a_ high-level 
language, such as that used to create the TwiddleNet software, most closely matches the 
abilities of the author; the author is familiar with application development, but has little 


experience with operating system or device driver development. 


The design of this implementation makes use of a network virtualization approach 
that allows TwiddleNet users to be partitioned into logical groups that can be combined 
to form virtual networks in arbitrary combinations. Consider the following scenario as an 
example. Suppose firefighters, medical personnel, and police are using TwiddleNet in 
response to a mass-casualty incident. These users can be placed into separate groups 
according to their role along with, for instance, an additional group for a command center 
at a hospital. The medical personnel wish to keep patient info they collect private 
allowing only other medical personnel and the command center to have access to it. The 
medics will configure their devices to share information only with their own group and 
the command center group. This effectively creates a separate virtual network, inclusive 
of only the medical and command center users, on top of the physical TwiddleNet 
network. Users in the firefighter and police groups, which are outside of this virtual 


network, will be unaware of any information passed by medical personnel. 
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The following figures illustrate the user-partitioning effect. Previous 
implementations of TwiddleNet did not allow for any user groups, and therefore, all users 
where essentially in a single group as depicted in Figure 2. As Figure 3 shows, the new 
implementation allows users to be organized into multiple groups while remaining 
connected to the same physical network. A user in one group can select other groups to 


share content with, dynamically creating virtual networks of groups as needed. 





User1 
User3 User4 
Userd User6 ( 
CommandPost 
\ User7 
— 
Figure 2. In previous implementations all users were in the same group 
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Figure 3. This implementation allows for grouping of users 
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B. DESIGN ASPECTS 


No changes to the physical components of the TwiddleNet architecture were 
necessary for this design. The new implementation of the TwiddleNet system still 
consists of the Portal, a number of Client devices, and the Command Post. The 
difference in this implementation is in system behavior. The design aspects and 
modifications made to the major TwiddleNet components in order to implement user 


groups are addressed here. 
1. Client 


A fundamental aspect of this implementation is that a TwiddleNet user can share 
information on a per-group basis. For this to be possible of course, the Client needs to be 
aware of what groups are available. To achieve this, the user sign-in process was 
modified to allow the Portal to send group information to the Client upon sign-in. These 
modifications are detailed in Chapter IV. This group information is used to build part of 
the Client’s graphical user interface (GUI) as described below. Transmittal of this 
information on sign-in is appropriate because group information will not change for the 
duration of the session. When the user signs in, he will receive group information that 


will be used for the remainder of the session. 


Some means of indicating to the user what groups are available and allowing him 
to select desired recipient groups is required as well. A GUI was designed for this 
purpose. Previous implementations of the TwiddleNet Client software already had a 
form-based System Setup GUI to allow the user to set system configuration parameters. 
Ableiter covers this GUI, including screenshots [25]. For this design a new tab was 
added to this form, labeled “RecipientOpt,” short for “Recipient Options.” Figure 4 


shows what this GUI would look like on a device running Windows Mobile 5. 
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SystemSetupForm 


Who to send Alerts to 


O Fire Fighters 
O Police 
oO Command Post 





CANCEL 
Figure 4. TwiddleNet Client Recipient Options tab 


The new tab displays the available TwiddleNet groups to the user and allows him 
to specify the groups that will receive a new alert by selecting a checkbox. By default, 
the group the user belongs to will be checked. The list of selected groups is saved 
internally by the Client software along with the information from other tabs when the 
user presses the “OK” button. Two other buttons labeled “AII” and “None” were added 
for convenience. These buttons can be used to select or deselect all of the groups on the 
list at once. The combination of groups selected by the user determines how alerts are 
generated by the Portal, as detailed in Chapter IV. For consistency sake, the look and 
feel of the tab, including object colors, font style, and font size were selected so as to 


match the style used on the other tabs in the form. 


After the user configures the Recipient Group options, this information is 
included in future notifications of new content that the Client sends to the Portal. This 
indicates to the Portal the groups that need to be alerted for the new content. The Portal 


will use this information to generate its alert address list as discussed below. 
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2. Portal 


a. Database Design 


The TwiddleNet Portal’s database is absolutely essential for the operation 
of the system as a whole. The database is used to store important system information 
including user credentials, group membership information, data about the devices being 
used in the system, such as IP address, and metadata for content that has been shared. 
The work for this implementation included a redesign of the database, preserving existing 
functionality while adding the functionality necessary to support user groups. Formal 
database design methods were used in the creation of this database, including Entity- 
Relationship (E-R) and Relational modeling. Details of the design are presented in the 
Appendix, including the E-R diagram, Relational model, and the Data Dictionary 
describing the database’s tables and attributes in detail. Important aspects of the database 


are highlighted below. 


(1) Portal Users Table. This table contains user identification 
information necessary for verification during the user sign-in process as well as linking 
users to groups in order to track group membership. The Portal Users Table, along with 
the Belongs To and Group Tables, is fundamental to the user-partitioning feature of this 


implementation. 


(2) Belongs To Table. This table maps users to groups by linking 
a unique user identifier from the Portal Users Table with a unique group identifier in the 
Groups Table. This allows the Portal to know what users belong in each group so an 


alert can be properly addressed when it is destined for a certain group. 


(3) Groups Table. This table stores the various groups available in 


the system. 


(4) Uses Table. This table links a particular user with the device 


he is using. This is done by linking a unique identifier for the user from the Portal Users 
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Table with a device identifier in the Devices Table. When an alert needs to go to a 
specific user, the IP address of the device being used by that user can be retrieved from 


the Devices Table via this linkage. 


(5) Devices Table. This table stores important identification 
information, including IP address, for the mobile devices being used in the TwiddleNet 


system. 


(6) Content Info Table. This table stores the metadata associated 


with content that has been shared. 


(7) Special Tags Table. This table is meant to store situation- 
specific information as determined by the system administrators and mission planners 
using the system. The current TwiddleNet implementation makes use of this table to 


store triage information as detailed in [25]. 


The database management system used for this implementation 
was MySQL. This choice was driven by the fact that MySQL is open-source and freely 
available. Moreover, MySQL allows for easy administration through the use of tools 


such as phpMyAdmin [31]. 
b. Sign-in Process 


As mentioned above, the design of the sign-in process was modified as 
part of this implementation. After verifying the user’s credentials, instead of simply 
sending an acknowledgement, the Portal now performs a database lookup and then sends 
a list of all available user groups, as well as the group to which that particular user 


belongs, to back to the Client. Details of this process are included in Chapter IV. 
c. Alert Addressing Process 


In previous TwiddleNet implementations the Portal would simply send an 
alert to all signed-in users when notified of new content being available. This required 
the Portal to generate a list of the IP addresses for all active client devices. The Portal did 


this by retrieving the IP addresses from its database. In this design the process was 
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modified so as to send an alert only to users in the groups indicated by the user sharing 
the content. The Portal now creates its alert recipient address list by gathering the IP 
addresses for users that are signed-in and who belong to one of the groups indicated in 


the new content notification. This process is discussed in detail in Chapter IV. 
Js Command Post 


No major changes to the Command Post software were necessary for this 
implementation. Administratively, the Command Post was placed in its own group in 
order to provide users a means of sharing content directly with it. The Command Post 
won’t receive an alert unless the user selects the Command Post group in the GUI as 


discussed earlier. 
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IV. IMPLEMENTATION AND TESTING 


A. IMPLEMENTATION TOOLS 


1. Software 


As this implementation builds upon past implementations which were written in 
the C# programming language, the programming for this work was also done in C#. The 
TwiddleNet Portal code is a console application based on the .NET 2.0 Framework, 
designed to be run on a PC. The TwiddleNet Client code is a Pocket PC application 
based on the .NET 2.0 Compact Framework, designed to be run on devices using the 


Windows Mobile 5 operating system. 


Microsoft’s Visual Studio 2005 Integrated Development Environment was used 
for development of the TwiddleNet software. Visual Studio is an excellent tool for 
development using .NET-based languages like C#. When integrated with the Pocket PC 
Software Development Kit, Visual Studio becomes a powerful platform for mobile 
development with built-in tools for easy deployment of code to the device and emulators 


for testing without an actual device. 


The MySQL Database Management System was used to host the TwiddleNet 
Portal’s database. In this implementation, MySQL was provided as part of the XAMPP 
[32] software suite. XAMPP is a_ cross-platform Apache-MySQL-PHP-Perl 
implementation that is very easy to setup and use. Using XAMPP, one can setup a web 
and database server simply by downloading the software and unpacking it. The software 
is self-contained and preconfigured so that the Apache web server supports PHP, 
allowing tools like phpMyAdmin to be used out of the box. Use of this software suite 
allows a TwiddleNet Portal to be setup quickly and easily. 


A few additional software tools are useful for the creation and management of the 


TwiddleNet Portal’s database. As previously mentioned, the Apache web server that is 
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part of the XAMPP suite allows for the use of phpMyAdmin, providing a web-based 
interface useful for the administration of MySQL databases. A new database can easily 


be created using this tool. 


Once an empty database for the Portal has been created, its structure must be 
defined and certain essential fields must be populated. Two SQL scripts were created for 
this purpose (see the Appendix). These scripts contain the SQL commands necessary to 
create the database structure and perform the initial population. Once these scripts have 


been run, the Portal database is ready for use. 


Taking advantage of the Apache web server included in the XAMPP package, a 
web-based interface, written in PHP, was created to simplify the management of the 
TwiddleNet Portal database. This administration web page can be used to create new 
TwiddleNet users and groups, assign users to groups, add devices to the database, and 
assign users to devices. Examples of the interface are seen in Figures 5 and 6. Figure 5 
shows what the User Listing page looks like and Figure 6 shows the page that is used to 


add a new user. 
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Figure 5. TwiddleNet Portal Database Admin Page, User Listing 
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TwiddleNet Admin: Add User 
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Figure 6. TwiddleNet Portal Database Admin Page, Creation of New User 
2. Hardware 


The mobile devices used to run the TwiddleNet Client software are HP iPAQ 
hw6945 smartphones. These devices are quite powerful with a large touch screen 
display, Qwerty keyboard, and multiple networking interfaces including WiFi (802.11 
WLAN), GSM (WWAN), and Bluetooth (PAN). The devices use the Windows Mobile 5 


operation system and run software based on the .NET Compact Framework. 


The TwiddleNet Portal can be run on any Windows machine capable of 
supporting the .Net 2.0 Framework. During development and testing this was typically a 
Windows XP laptop or an OQO Ultra Mobile PC also running Windows XP. The small 
size and portability of the OQO makes it convenient for use in a mobile system like 


TwiddleNet. 


For demonstration and testing the TwiddleNet machines are provided IP addresses 


via the Dynamic Host Configuration Protocol (DHCP). A laptop running Windows 


Zo 


Server 2003 is used for this purpose. For convenience, the Command Post software is 


also run on this machine along with the Apache web server that supports it. 


In the lab an 802.11 access point is typically used to create a stand-alone WiFi 
network for demonstration and testing. In actual usage an access point in a host network 


or some form of mobile access point may be utilized. 
J. Lab Network 


Figure 7 shows how the TwiddleNet system is arranged in the lab for testing and 
demonstration purposes. The access point creates a stand-alone WiFi network. The 
DHCP server provides IP addresses to the various components. The Access Point, Portal, 
and Command Post use reserved addresses while the Clients receive address dynamically 


from a specific range. 
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Figure 7. TwiddleNet Lab Network 
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B. NEW TWIDDLENET SYSTEM OPERATION 


1. Overview 


The following is a high-level overview of the new TwiddleNet System operation. 
Figure 8 illustrates the user-partitioning feature of the new implementation. Here the 
Client devices are organized into three separate groups instead of a single group as in 


Figure 1. 
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Figure 8. New TwiddleNet System Operation 


The new system operation can be illustrated using an information sharing scenario 
like that discussed in Chapter I. Here, unlike in the previous discussion, the TwiddleNet 
users are broken up into separate groups, named A, B, and C, for the purpose of 
discussion. The Command Post is assigned to a separate group on its own. In this 
scenario a user in Group A wishes to share content with users in Group C and the 


Command Post but not with other users in Group A or with those in Group B. 
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The scenario begins with the user starting the TwiddleNet Client software and 
signing into the Portal. By the time the sign-in process is complete, the Client will have 
received the group information necessary to populate the Recipient Options tab of the 
System Setup GUI (discussed in Chapter III) from the Portal. The user would then select 
Group C and the Command Post group while leaving Groups A and B unselected. Now 


the Client software is configured according to the user’s preferences for alert recipients. 


When the user shares content, like in previous implementations, a notification is 
sent to the Portal containing metadata for the shared content. In the new implementation 
this metadata also contains the groups specified by the user for alert receipt, namely 


Group A and the Command Post group (Figure 8, Step 1). 


After the Portal receives the notification of new content, it sends an alert to the 
Clients in the specified groups only, instead of all other active Clients. So Clients in 
Group C and the Command Post are notified that new content is available (Figure 8, Step 
2). Other users in Group A as well as those in Group B will not receive an alert and will 
therefore not have access to that content. After receiving an alert, a user wishing to 


download the content may do so as discussed in Chapter IL. 
2 System Operation Description 


This section contains a more detailed description of important aspects of the new 
TwiddleNet System operation. For the purposes of this discussion the information- 
sharing process is broken down into the four major steps: 1) sign-in, 2) Recipient Options 


configuration, 3) notification of new content, and 4) alert generation and transmittal. 
a. Sign-in 


The sign-in process (illustrated in Figure 9) begins with the user entering 
his user name and password when prompted by the TwiddleNet Client software running 
on the handheld device. The Client then creates a TCP connection with the Portal and 
sends the user name and password entered by the user, the device’s MAC addresses, and 
two hash values, for the user name and password, respectively. The hashed user name is 


used as a unique identifier for Portal Users records in the Portal’s database (see 
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Appendix). As a security precaution, the Portal stores a hash value of the password to 
avoid keeping a plain-text version. The MAC address is currently not used, but was 
considered by previous TwiddleNet developers to be potentially useful for future 


software features. 


After receiving this information the Portal processes it. The first step in 
processing is to validate the user by comparing the user name and password hashes it was 
passed to those stored in its database. If the passed-in values don’t match, the Portal will 
send an error message to the Client. The Client will then prompt the user to try the sign- 


in again or quit. 


If the user is successfully validated, the Portal will then check the device 
IP address stored in the Devices record (see Appendix) associated with the user and 
update it if necessary (the Portal has access to the device’s current IP address via the TCP 
connection). This is one way in which the Portal keeps track of the current IP address of 


active devices. For further details on Client IP address tracking see [25]. 


Next, the Portal will retrieve the name of the group the user belongs to as 
well as a list of all existing groups. This information is then sent to the Client along with 
an acknowledgement message to indicate successful sign-in. The Client will store this 


group information internally and use it to build the Recipient Options tab on the System 


Setup GUI as discussed in Chapter IIL. 
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Figure 9. User Sign-in Process 
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b. Recipient Options Configuration 


As previously mentioned, the TwiddleNet Client software uses the group 
information it receives from the Portal as part of the sign-in process to build the Recipient 
Options GUI (see Figure 4) that the user will use to indicate which groups should receive 
alerts for future shared content. By default, only the user’s group will be selected, so if 
he makes no configuration changes, content will be shared only with the other users in his 
group. If the user desires to share with groups other than his own, he will call up the 
Recipient Options configuration and select additional groups. If all groups are selected, a 
special flag is set indicating the content is public. After the user presses the “OK” button, 
the selected group names will be saved internally for future use by the Client software 


when building notifications destined for the Portal. 
c. Notification of New Content 


When a user shares content, the TwiddleNet Client software builds a 
notification message for that item. This message is in XML format and includes 
metadata describing the content as well as the recipient group information saved earlier. 


An example of a notification message is shown below. 


<?xml version="1.0" encoding="utf-8"?> 
<TNetMessage> 
<content> 
<user name>Teamla</user name> 
<task>SHARE</task> 
<tags> 
<filename>T-Ten0016.jpg</filename> 
<file_ size>171805</file size> 
<file type>jpg</file type> 
<public>True</public> 
<date_created>2008-09-24T16:49:24</date_created> 
<date_shared>2009-01-15T12:09:54</date_shared> 
<rec_groups> 
<group_list> 
<group_namel>CommandPost</group_namel> 
<group name2>Fire Fighters</group name2> 
<group_name3>Medics</group_name3> 
<group_name4>Police</group_ name4> 
</group_list> 
</rec_groups> 


30 


<special tags> 
</special tags> 
</tags> 
</content> 
</TNetMessage> 


This example shows that a picture (T-Ten0016.jp) has been shared with 
four groups included in the <group_list> tag. These four groups happen to represent all 
the groups implemented in the system so the <public> tag contains the value “True.” The 


value of this flag affects the behavior of the Portal when it processes notifications as 


discussed below. 


After the notification message has been built, the Client opens a TCP 
connection with the Portal and sends the message. The Portal parses and stores the 
metadata contained in the message, then responds with an acknowledgement or an error 
message if the notification couldn’t be processed properly. When the Client receives an 
acknowledgement, the GUI is updated indicating the content was successfully shared. 
Otherwise an error message is displayed to the user. The notification process is 


illustrated in Figure 10. 


Client sends: 
notification 
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Client builds. 
notification 


a Portal 


Portal sends 
ACK, Client 
updates GU] 


Portal sends. 
Error, Client 
displays error 
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Figure 10. Client-Portal Notification Process 
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d. Alert Generation and Transmittal 


When the Portal receives a notification message for new content, it must 
process the information. This includes parsing the message and storing the metadata 
found therein in a new ContentInfo record in its database (see Appendix). The Portal also 
stores the recipient groups contained in the notification message internally for future use 


in alert generation. 


After the incoming information has been processed, the Portal builds the 
alert message that will be sent to other users alerting them of the availability of new 
content. The alert message is also an XML message in the same format as the 
notification message. Unlike in previous implementations where the Portal simply sent 
an alert to each active user, here the Portal sends the alert only to the users belonging to 
the groups specified in the notification message. In order to achieve this the Portal uses a 
nested SQL query to first pull the user names belonging to the groups included in the 
notification message from its database, and then pull the IP addresses associated with the 
devices assigned to all active users in that list. The result is a list containing the IP 
address associated with the device being used by each user belonging to the recipient 


groups indicated by the user sharing the content. 


After the IP address list has been generated, the Portal sends the alert 
message to each user’s Client via the address for their device on the list. As in previous 
implementations, this is done in a multithreaded manner freeing the main Portal process 
so that it may handle other communications and ensuring that alerts are sent in a timely 


manner. 
C. IMPLEMENTATION ISSUES 


In this section notable implementation-specific issues are discussed. For this 
implementation a few changes were necessary to address issues and make improvements 
in the TwiddleNet code. Theses changes involved the use of hash functions as well as 


XML parsing methods. 
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1. Hash Functions 


In the previous implementation a .NET-specific hash function was used to 
generate hash values for user names and passwords. This did not pose a problem in the 
past because the only software that handled these values was based on the .NET libraries. 
The new implementation, however, allows for user records of the Portal database, 
including user name and password hashes, to be created using the previously mentioned 
web-based administration interface. When user records are created using this tool, hash 
values must be created using functions available in PHP. Since the algorithm used by the 
-NET hash function was unknown, and therefore impossible to replicate using PHP, the 
author was unable to create a hash value in PHP that matched the value produced by the 
.NET function when hashing the same string. This affected the user sign-in process, as 
user validation was impossible for users created via the web-based administration tool. 
Since MD5 hashes can be created in both .NET and PHP, the TwiddleNet code was 
modified to use an MDS hash function. In this way a string, such as a user name or 
password, when hashed by a PHP function, produces the same value as that produced by 
the .NET hash function when hashing the same string, and can be compared during user 


validation without problems. 


2. XML Parsing 


Much of the Client-Portal communication in TwiddleNet relies on the use of 
XML. Consequently, the Client and Portal code must be able to parse XML documents 
in order to retrieve the information embedded within. The previous implementation was 
rather inflexible in the manner in which this parsing was implemented. The code that 
parsed an XML document depended heavily on the structure of the document. It used 
nested if-else statements that corresponded directly to the structure of the XML 
document. In other words, if the XML document had tags that were nested three levels 
deep, the parsing code had to have if-else statements nested three levels deep. Thus, any 
change to the structure of the XML document necessitated a great deal of work changing 


the parsing code. 
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The issue was addressed in this implementation through the use of a recursive 
XML parsing method. This makes the parsing code independent of the structure of the 
XML document itself. The method can parse an XML document no matter how many 
levels of nesting are used. Furthermore, the code does not need to be rewritten if the 
structure of the XML document is changed. This will ease the burden on programmers as 


future changes are made to the system. 
D. TESTING 


The new TwiddleNet implementation was tested in January 2009 as part of the 
Cooperative Operations and Applied Science and Technology Studies (COASTS) Field 
Experiment II (FEX-II) at Camp Roberts, California. TwiddleNet researchers have been 
involved with the COASTS project for some time as it provides an excellent test bed. 
The COASTS field experiments give researchers an opportunity to run TwiddleNet in a 


real-world environment outside the confines of the lab. 


Rather than being run in its own self contained network, as it is for lab testing and 
demonstration, during the FEX TwiddleNet was integrated into the greater Camp Roberts 
network. Figure 11 shows how the TwiddleNet network was arranged during the FEX 


testing. 
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Figure 11. TwiddleNet Integration into Camp Roberts Network 
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TwiddleNet was assigned a block of addresses belonging to the Camp Roberts 
network for use during the FEX. All TwiddleNet components were assigned static 
addresses from this block as seen in Figure 11. An access point was available to provide 


connectivity via WiFi. 


The user-partitioning feature of the new TwiddleNet implementation was 
successfully tested during the FEX. Users were organized into three different groups and 
content was shared to various combinations of groups. The only difficulty experienced 
had to do with the distance of devices from the access point. If the devices were more 
than approximately 60 yards away, content transfers between the devices and from the 
devices to the Command Post failed. It is believed that this is due to the relatively lower 


signal strength at the periphery of the access point’s coverage range. 


Another notable aspect of the FEX testing centered on a new tool called the 


TwiddleNet Gateway. The TwiddleNet Gateway is a piece of software that interfaces 
2D 


TwiddleNet with external systems allowing content to be shared from sources other than 
TwiddleNet Clients. While not necessarily related to the work done for this thesis on 
privacy protection, the Gateway software does take advantage of the user-partitioning 
feature developed as part of this work. This allows the Gateway to share content it 
receives from external sources with TwiddleNet users on a per-group basis much like a 


standard TwiddleNet Client can. 


The TwiddleNet Gateway was included as part of the TwiddleNet network during 
the FEX testing (see Figure 11). Content was shared with the Gateway over a VPN 
connection with the wireless lab at the Naval Postgraduate School (NPS) using the 
External System Simulator (ESS). The ESS is a simple program designed to simulate a 
content feed that might be provided from an external system. The ESS provides a 
notification of new content to the Gateway, which then retrieves the content and shares it 


with other TwiddleNet users. 


Overall the FEX testing was very successful. The ease at which TwiddleNet is 
able to be integrated into other networks like the Camp Roberts network is due in no 
small part to the decisions made by previous designers, who chose to base all TwiddleNet 


communications on universal standards such as TCP/IP and HTTP. 
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V. CONCLUSION AND FUTURE WORK 


A. CONCLUSION 


This work successfully implemented privacy protection for TwiddleNet, a 
network of mobile devices intended for use by first responders. As the user-partitioning 
feature of this implementation shows, network virtualization is an appropriate choice for 


implementing privacy in mobile networks. 


As discussed in Chapter I, this work focused on the requirement of content 
privacy. This implementation partially meets this requirement in that content is protected 
from inadvertent release to unauthorized users, but not protected from eavesdropping. In 
other words, the threat from casual observers is addressed, but the attacker threat is not 
addressed. An attacker, with advanced knowledge of networking and the use of 
specialized “sniffing” tools, could still gain access to content shared by TwiddleNet 
users, compromising their privacy. Properly addressing this threat calls for a more 
sophisticated approach, perhaps incorporating techniques mentioned in Chapter II, and is 


left to future work. 


In just a few short years TwiddleNet has become a robust and useful system, 
improving with each incremental development step in order to better meet the needs of 
first responders. This work realizes the latest step forward in that progression. It is the 


sincere hope of the author that this progression continues for years to come. 
B. FUTURE WORK 


This work represents the first step toward improving the overall security posture 
of the TwiddleNet System. Much more can be done to improve the privacy, security, and 


availability of the system. Some ideas for future work are presented below. 
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1; End-to-End Encryption 


Currently, even if mechanisms such as WEP or WPA are enabled in order to 
protect content in the wireless medium, the system could still be vulnerable to an attacker 
capturing packets on any wired links. An end-to-end encryption scheme utilizing 
technology like Secure Sockets Layer (SSL) could be used to address this. Furthermore, 


encryption keys used in such a scheme could also be used in support of authentication. 


The use of SSL proves challenging, however, due to the implementation platform 
used for the TwiddleNet Client software, as the .NET Compact Framework 2.0 does not 
support SSL connections. Third-party libraries, such as those provided by UDAParts 


[33], may provide a way forward in SSL-enabling TwiddleNet communications. 
2. Addressing the Single-Point-of-Failure Issue 


The TwiddleNet Portal represents a potential single-point-of-failure in the system. 
If the Portal fails, all content metadata, as well as user and group information, will no 
longer be accessible. Furthermore, client communications will no longer be possible as 
the Portal is central to all sharing, alerting, and transfer of content. Providing a 
mechanism for redundancy or making the system architecture more distributed could 


greatly improve the overall availability of the system. 
3: Software Engineering 


The TwiddleNet project could benefit greatly from a formal software engineering 
effort. This should include requirements definition, use case analysis, and formal UML 
documentation. This would not only help newcomers to the project who need to learn the 
software, but also would provide a basis for future implementation on platforms other 
than .NET. The design should be done with extensibility in mind so that future 
modifications and additions are easier. In addition, the documentation should be updated 


as new features are added or other changes are made. 
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4. Command Post Improvements 


A few improvements to the Command Post software would go a long way toward 
increasing its usefulness. Currently the web page that the software builds is mostly static. 
There is the ability to append information to the metadata displayed, but no new content 
is shown until the page is refreshed. Implementing the page using technology like 
Asynchronous Java and XML (AJAX) could address this. With AJAX, a portion of a 


web page can be updated without refreshing the entire page. 


The current implementation of the Command Post is receive-only in that it 
displays only content shared from TwiddleNet clients but cannot share content itself. 
Another potential improvement to the software would be to add the ability to share 
content just like a standard TwiddleNet Client. A technology like AJAX could possibly 
be used here as well, creating a web-based application that could be used to view content 
and its associated metadata, update that information, and send the updates back out to 


Clients. 
a Integration with Other COASTS Systems 


There may be great benefit derived from the integration of TwiddleNet with other 
systems that are part of the COASTS program, specifically the Real-Time Automated 
Position Identification System (RAPIDS) and the perimeter security system being tested 
during COASTS experiments. 


RAPIDS is a three dimensional positioning system used for situational awareness 
and command and control purposes. Using RAPIDS, the position of an Unmanned 
Aerial Vehicle (UAV), for example, can be tracked on a common operational picture. 
Integrating TwiddleNet with RAPIDS could allow images taken from the UAV to be 
distributed to teams on the ground, potentially providing real-time intelligence or other 


tactical data. 
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TwiddleNet could also be integrated with the perimeter security system used in 
COASTS experiments. For example, TwiddleNet could be used to distribute pictures of 
contacts of interest, such as suspicious vehicles or illegal immigrants, to border security 


teams. 
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APPENDIX 


TwiddleNet Portal Database Entity-Relationship Diagram 
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TwiddleNet Portal Database Relational Model 


PortalUsers (UserId, UserName, PswdHash, Role, RcvPubAlerts) 
Groups (GroupId, GroupName, MissionNum) 


BelongsTo (Userld, GrouplId) 





Devices (Deviceld, [PAddr, MACAddr) 


Uses (Userld, Deviceld, TimeSignedIn) 
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Missions (MissionNum, Description, Duration, Location) 


ContentInfo (ContentId, Filename, FileSize, FileType, Public, Cached, DateCreated, 
DateShared, LastRequest, TagNum, UserlId) 


SpecialTags (TagNum, SpecDatal, ... , SpecDataN) 


TwiddleNet Portal Database Data Dictionary 


Assumptions 

e A user must belong to at least one group. 

e Userlds are unique. 

e A user may be sharing zero or more pieces of content at any given time. 

e A particular file may be shared by more than one user, but one ContentInfo record is 


associated with only one user. 

e A.user can’t share the same content more than once. 

e Auser can only log in to the system from one device at a time. 

e A device that isn’t being used to run the TwiddleNet application isn’t associated with 
the system. 

e A device can only have one IP address at a given time (if both WiFi and GPRS radios 
are enabled at the same time, the device will associate with the WiFi access point 
only). 

e A group can only be assigned to one mission at a time. 


Data Dictionary 


Entity: PortalUsers — All the users currently registered to use TwiddleNet 
Attributes: 
e Userld — A unique identifier for the user signed into TwiddleNet. 
UserName — The name of the user identified by Userld. 
PswdHash — The value resulting from hashing the user’s password. 
Role — The role the particular user plays within the group. 
RevPubAlerts — Boolean value indicating whether or not this user should receive 
public alerts. 


Entity: Groups — The different groups the users are organized into. 
Attributes: 
e Groupld — A unique identifier assigned to the group. 
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e GroupName — The name of the group. Ex: “Red Cross”. 


Entity: Devices — The devices currently associated with the system. 


Attributes: 
e DeviceID — A unique identifier for the device; used for database implementation 
purposes. 


e MACAddr — The MAC address of the device being used by the associated user. 
e IPAddr— The IP address currently assigned to the device being used by the 
associated user. 


Entity: ContentInfo — Information describing the content that the associated user is 
sharing. 
Attributes: 
e ContentId — A unique identifier for the content. 
Filename — The filename of the content being shared. 
FileSize — The size (in memory) of the file. 
FilesType — The file extension of the content. 
Public — A boolean indicating whether or not the content should be available to all 
users or just the group associated with the sharer. 
Cached — A boolean indicating whether or not the content is cached on the Portal. 
DateCreated — Date the content was created. 
DateShared — Date the content was shared. 
LastRequest — Date and time the content was last requested from the sharer. 


Entity: SpecialTags — Extended information describing the content specific to a particular 
situation. 
Attributes: 
e TagNum - A unique integer identifying a particular SpecialTags record. 
e Only generic attributes are named at this time. For example SecDatal, etc. for 
Special Data Items. 


Entity: Missions 
Attributes: 
e MissionNum — A unique identifier for the mission. 
e Description — A description of the mission. For instance, purpose. 
e Duration — Number of hours the mission is expected to last. 
e Location — The geographic location the mission is to take place at. 


Relationships: 
e BelongsTo — Relates users to the groups they belong to. 
e Uses — Relates a user to the device that user is currently using. 
o Attributes: 
=  TimeSignedIn — The time the user signed into TwiddleNet. 
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e Shares — Relates particular ContentInfo items to the user sharing the associated 
content. 

e Contains — Relates SpecialTags with the associated ContentInfo. 

e AssignedTo — Relates missions with groups that are performing them. 


Portal Database SQL Scripts 
Script to create empty database: 


CREATE TABLE portalusers ( 
user_id CHAR(32) PRIMARY KEY, 
user_name VARCHAR(100) UNIQUE, 
pswd_hash CHAR(32), 
role ENUM ("GroupLeader", "GroupMember"), 
rcv_pub_alerts BOOLEAN 


) 


CREATE TABLE missions ( 
mission_num VARCHAR(10) PRIMARY KEY, 
description TEXT, 
Duration INT, 
Location VARCHAR(100) 


) 


CREATE TABLE groups ( 
group_id INT PRIMARY KEY AUTO_INCREMENT, 
group_name VARCHAR(100), 
mission_num VARCHAR(10), 
CONSTRAINT groups_msn_num_fk FOREIGN KEY (mission_num) 
REFERENCES missions(mission_num) ON DELETE SET NULL 
ON UPDATE CASCADE 


) 


CREATE TABLE belongsto ( 
user_id CHAR(32) NOT NULL, 
group_id INT, 
CONSTRAINT bel_to_user_id_grp_id_pk PRIMARY KEY (user_id, group_id), 
CONSTRAINT bel_to_user_id_fk FOREIGN KEY (user_id) 
REFERENCES portalusers (user_id) ON DELETE CASCADE 
ON UPDATE CASCADE, 
CONSTRAINT bel_to_grp_id_fk FOREIGN KEY (group_id) 
REFERENCES groups (group_id) ON DELETE CASCADE 
ON UPDATE CASCADE 
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CREATE TABLE devices ( 
device_id INT PRIMARY KEY AUTO_INCREMENT, 
ip_addr VARCHAR(100) DEFAULT 'TempValue'’, 
mac_addr VARCHAR(100) DEFAULT ' TempValue'’, 
batt_level INT DEFAULT 0, 
device_sn VARCHAR(30) UNIQUE DEFAULT ' TempValue' 


) 


CREATE TABLE uses ( 

user_id CHAR(32) PRIMARY KEY, 

device_id INT, 

time_sig_in TIMESTAMP, 

CONSTRAINT uses_user_id_fk FOREIGN KEY (user_id) 
REFERENCES portalusers(user_id) ON DELETE CASCADE 
ON UPDATE CASCADE, 

CONSTRAINT uses_device_id_fk FOREIGN KEY (device_id) 
REFERENCES devices(device_id) ON DELETE NO ACTION 
ON UPDATE CASCADE 

); 


CREATE TABLE specialtags( 
tag_num INT PRIMARY KEY AUTO_INCREMENT, 
gender VARCHAR(100), 
age VARCHAR(100), 
last_name VARCHAR(100), 
first_name VARCHAR(100) 
); 


CREATE TABLE contentinfo( 

content_id INT PRIMARY KEY AUTO_INCREMENT, 

filename VARCHAR(100), 

file_size VARCHAR(100), 

file_type VARCHAR(10), 

public_yn BOOLEAN, 

cached BOOLEAN DEFAULT false, 

date_created DATETIME, 

date_shared DATETIME, 

last_request DATETIME, 

tag_num INT NOT NULL, 

user_id CHAR(32) NOT NULL, 

CONSTRAINT contentinfo_tag_num_fk FOREIGN KEY (tag_num) 
REFERENCES specialtags(tag_num) ON DELETE CASCADE 
ON UPDATE CASCADE, 

CONSTRAINT contentinfo_user_id_fk FOREIGN KEY (user_id) 
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REFERENCES portalusers(user_id) ON DELETE CASCADE 
ON UPDATE CASCADE 


Script to create initial database information: 
INSERT 


INTO specialtags (gender, age, last_name, first_name) 
VALUES (‘None supplied’, 'None supplied’, 'None supplied’, 'None supplied’) 
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